See how the foreman project compares to other vendors in security performance
The reported issue is a valid object-level authorization bypass in Foreman's template revision handling.
TemplatesController#revision (app/controllers/templatescontroller.rb) loads the requested audit with Audit.find(params[:version]). The corresponding API controllers use Audit.authorized(:viewauditlogs).find(params[:version]). The UI action is a collection endpoint and is not subject to findresource, so authorization checks only whether the user may invoke the action (for example viewptables). It does not authorize the specific audit object supplied by the user.
An authenticated, low-privileged user with a template permission such as viewptables, scoped to one organization or location, can therefore retrieve a historical template revision from another organization or location by supplying its audit identifier. This is possible without viewauditlogs and without access to the template through the normal template API. The same revision action is inherited by partition table, provisioning template, report template, and remote execution job template controllers.
The exposed data is the historical template content, which may include sensitive configuration, credentials, or other secrets depending on customer configuration. This unrestricted lookup has been present since the introduction of STI templates.
A flaw was found in Foreman. An authenticated user with host-edit permissions could exploit a cross-tenant information disclosure vulnerability. This flaw occurs because the taxonomyscope controller method does not properly validate organization and location IDs from nested request parameters, bypassing existing authorization checks. This allows the user to leak sensitive infrastructure metadata, including subnet topology, IP ranges, gateways, DNS servers, and VLAN IDs, from organizations and locations they are not authorized to access.
Summary: A cross-tenant information disclosure flaw was found in Foreman. The taxonomyscope controller method does not validate organization and location IDs from nested request parameters against the current user's taxonomy memberships, bypassing the existing settaxonomy authorization check. This flaw allows an authenticated user with host-edit permissions to leak infrastructure metadata such as subnet topology, IP ranges, gateways, DNS servers, and VLAN IDs from organizations and locations they do not belong to.
Requirements to exploit: Authenticated Foreman account with createhosts or edithosts permission (or equivalent hostgroup permissions) in at least one organization. Attacker crafts a single HTTP request with a valid own-org ID at the top level and a foreign org ID in nested params.